bảo mật vcil

Cách hiểu rộng cho copyleft

cách Vcil dùng từ "copyleft" không gắn với định nghĩa FSF, mà phản ánh một tinh thần rộng hơn

Việc mở rộng nghĩa của một khái niệm là một hiện tượng ngôn ngữ xảy ra hằng ngày và hoàn toàn bình thường. Tuy nhiên, để cách hiểu mở rộng được chấp nhận thì cần sự đồng tình của những người đã vốn sử dụng nó trước đó. Ở đây, khái niệm copyleft là do cộng đồng những người làm phần mềm đặt ra và được FSF hoàn thiện, quảng bá trong 40 năm rồi. Nên nếu muốn mở rộng nghĩa của nó ra thì cần có sự đồng tình của những người có đã sử dụng nó trước đó. Giống như trước giờ từ "con mèo" đã được sử dụng rộng tãi để mô tả một loài động vật kêu meo meo. Nay các bạn nói rằng các bạn sử dụng từ đó theo "tinh thần rộng hơn", nên là cái con sủa gâu gâu các bạn cũng gọi là con mèo, thì sẽ chẳng ai chấp nhận cả, dù về nguyên tắc không ai có quyền cấm các bạn. Ai nặng nề thì sẽ gọi đây là đánh tráo khái niệm, còn mình thì nghĩ đơn giản là do các bạn chưa hiểu nó thôi.

Mình hiểu ý các bạn muốn nói là bất kỳ ai cũng có thể học, ứng dụng, và phát triển các ý tưởng, mô hình và cách vận hành của Vcil, vì chúng được chia sẻ tự do. Các bạn dùng từ copyleft vì nó thể hiện sự đối lập mạnh mẽ với copyright (bản quyền, tác quyền, quyền tác giả). Nhưng có mấy điều:

Để nói là các ý tưởng, mô hình và cách vận hành của Vcil được chia sẻ tự do, các bạn chỉ cần nói là các bạn không đăng ký bằng sáng chế (patent) cho chúng là được. Còn nếu các bạn vẫn nói rằng những gì các bạn làm là copyleft, thì các bạn vẫn có nghĩa vụ cung cấp mã nguồn các phần mềm các bạn viết, kể cả website.

Và cuối cùng, đảm bảo vấn đề bảo mật là nghĩa vụ của các bạn. Nếu vì nghĩa vụ bảo mật mà phải tạm gác lại nghĩa vụ cung cấp mã nguồn thì các bạn có nghĩa vụ giải thích điều đó cùng với kế hoạch để giải quyết. Mình biết là vấn đề thì phức tạp và các bạn quá nhiều việc để làm, nên mới hỏi để giúp các bạn hoàn thành nghĩa vụ của các bạn được tốt hơn. Xong rồi các bạn lại nói là mình "có hành vi chưa phù hợp với các nguyên tắc và giá trị chung của cộng đồng".

Bảo mật

Các bạn nói lý do không chia sẻ mã nguồn:

Nó là một sản phẩm kỹ thuật đang trong quá trình xây dựng, chứa dữ liệu vận hành của cộng đồng, và có những phần chưa ở trạng thái ổn định để chia sẻ rộng rãi mà không gây rủi ro

Như mình có phân tích là dữ liệu vận hành của cộng đồng không phải là mã nguồn, nên lý do này là không hợp lý. Còn về ý gây rủi ro thì mình nghĩ ý của các bạn là vấn đề về bảo mật. Có lẽ giả định của các bạn là nếu kẻ tấn công không biết về mã nguồn thì sẽ làm giảm khả năng tấn công. Đây là hình thức bảo mật bằng việc che giấu (security through obscurity).

Việc giữ kín mã nguồn đúng là có tác dụng cản trở những kẻ tấn công có trình độ tầm thường (giống như mình): có thể đọc hiểu mã nguồn, nhưng nếu không có thì không biết tấn công làm sao. Nhưng sẽ có bao nhiêu người đọc mã nguồn của các bạn? Hẳn là người đọc phải đủ quan tâm tới các bạn tới một mức độ nhất định, đồng thời cũng có đủ trình độ để đọc thì mới thấy việc đó là đáng thời gian. Nếu có ý định tấn công thì còn phải thấy việc đó đáng làm hơn những chuyện khác. Nên mình cho rằng thì xác suất bị tấn công bằng phương pháp đọc mã nguồn là hoàn toàn chấp nhận được.

Vả lại, việc phòng thủ với loại đối tượng tấn công này mình nghĩ cũng không có gì khó: không để mật khẩu hay khóa xác thực trực tiếp trong code mà để trong tệp môi trường (.env), không để lộ thiên trang quản trị, v.v. Những điều này mình nghĩ ai từng lập trình đều có thể nhận ra. Có vô vàn dự án mới, cũng chưa hoàn thiện và chưa ổn định giống như phần mềm của các bạn, nhưng người viết ra chúng cũng không lo lắng gì khi chia sẻ mã nguồn. Mình thấy việc này hoàn toàn nằm trong khả năng của các bạn.

Nên mình thấy có thể bỏ qua loại đối tượng tấn công có trình độ hạn chế, chỉ có thể dựa vào lỗi sơ đẳng được thể hiện rõ trong mã nguồn để tấn công. Vậy với những loại đối tượng tấn công có trình độ cao hơn thì sao? Thì khả năng cao là họ cũng chẳng cần đến mã nguồn để tấn công. Có vô số kỹ thuật tấn công thông minh mà hoàn toàn không cần biết đến mã nguồn, tại sao họ phải tốn công đọc nó làm gì? Những kẻ tấn công thậm chí có thể còn biết về mã nguồn của các bạn nhiều hơn là các bạn biết. Và họ cũng có thể chẳng cần tự đi tấn công, mà viết virus, malware, trojan để tấn công tự động là được. Mình đã từng bị dính rồi. Gửi các bạn hình trang web của mình hồi đó:
Hacked by LittleDemon.png
Cách tấn công này gọi là defacement, ở đó kẻ tấn công làm biến dạng website.

Việc phòng thủ với loại tấn công này mình nghĩ phụ thuộc vào trình độ bảo mật của lập trình viên. Các lỗi bảo từng mật phổ đều cũng đã có nhiều. Nếu ngay từ đầu người lập trình có ý thức về bảo mật ngay từ đầu (secure-by-design) và sử dụng các công cụ, khung làm việc có các thiết lập mặc định là bảo mật (secure-by-default), thì việc phòng thủ với những người này cũng không phải là tốn công.

Nhưng dù là với đối tượng tấn công nào đi nữa, mình thấy với ý của các bạn thì có 2 khả năng:

Các bạn hiểu rằng code còn lỗ hổng bảo mật, nhưng không có đủ nguồn lực để sửa nó. Các bạn thấy là còn nhiều vấn đề khác cần được ưu tiên hơn
Các bạn không chắc là code có còn lỗ hổng nào hay không, nên nghĩ rằng cứ giữ kín cho chắc ăn

Nếu là trường hợp 1, thì nghĩa là những nguyên tắc bảo mật đã không được áp dụng. Giống như các bạn xây cất một cái nhà nhưng cây thu lôi lại không hoạt động. Việc cái bản thiết kế của cái nhà được chôn dưới đất không phổ biến tới đâu có làm cho cái nhà trở nên an toàn hơn? Việc công khai bản thiết kế hay không là chuyện của các bạn, còn sét có đánh hay không là chuyện của trời. Tác dụng duy nhất của việc không ai biết cây thu lôi có hoạt động hay không là trấn an tâm lý người dùng rằng nó có hoạt động. Đây đâu phải là bảo mật, mà là trình diễn bảo mật (security theater).

Còn ở trường hợp 2, đó là có thể sản phẩm không có lỗ hổng nào cả, nhưng các bạn không chắc là có hay không. Tức là các bạn không tự tin vào năng lực lập trình của mình, ít nhất là ở việc đọc code. Mà nếu các bạn không dám chắc là code nói gì, thì các bạn cũng không loại trừ được khả năng có một lỗi vận hành nào đó, chẳng hạn như làm hỏng hoặc xóa dữ liệu. Tức là lúc này, chưa cần nghĩ tới việc bị tấn công, bản thân việc sử dụng nó thôi cũng đã là rủi ro rồi. Nếu các bạn thấy mình có trách nhiệm bảo vệ người dùng, thì tốt nhất là dừng việc sử dụng nó cho tới khi các bạn tự tin hơn về cách nó hoạt động, hoặc nói rõ cho họ biết là sản phẩm này còn rủi ro.

Con người thường xuyên là điểm dễ bị tấn công nhất. Trong trường hợp này, mình nghĩ thứ kém bảo mật nhất ở đây chính là các bạn chứ không phải là mã nguồn. Về cơ bản, các bạn không đánh giá được mức độ bảo mật của hệ thống mình thế nào, và khi phòng thủ thì lại sai đối tượng. Ngay việc cho rằng chia sẻ mã nguồn là gây rủi ro hay đồng nghĩa với việc tham gia xây dựng website đã thể hiện là các bạn đang không hiểu những gì các bạn đang làm rồi.

Mình đã viết phần về bảo mật này khá dài. Thật ra, toàn bộ phần này mình có thể chỉ cần nói một đoạn thế này:

Dịch vụ tạo và phục vụ website (website builder & hosting) các bạn đang sử dụng, Webflow, công bố rằng việc bảo mật đã được tính đến từ giai đoạn thiết kế (secure-by-design). Nếu các bạn không chèn script ngoài thì mình nghĩ là có thể yên tâm về độ bảo mật của website các bạn. Nhưng dù sao thì mình cũng không có đủ kiến thức bảo mật để đánh giá, và mình đọc thì cũng chưa rõ nó sẽ đảm bảo sản phẩm các bạn tạo ra tuân thủ các nguyên tắc lập trình bảo mật thế nào. Để chắc ăn các bạn nên thuê một đơn vị chuyên về bảo mật để họ kiểm tra và tư vấn cụ thể.

Mình ghi dài vì mình thấy cần phân tích kỹ những quan niệm mà các bạn đang sử dụng. Những quan niệm này là phổ biến, nhưng lại dựa trên các giả định sai.